There is, and will continue to be, advances and changes in how enterprises conduct business. Whether these advances and changes occur through growing competition and globalization, mergers and acquisitions, or a revamping of business models, the key for success will often depend on how quickly the enterprise's information technology (IT) organization can adapt to evolving business needs. Therefore, a major challenge to these enterprises is how they handle change.
For organizations to enable business agility, they must ensure that enterprise applications are not only high-performance business engines driving efficiencies, but also that they become flexible building blocks of future business systems. A recent promising solution has risen in the form of services. A service, such as a Web service or program, represents a self-contained, self-describing piece of application functionality that can be found and accessed by other applications. A service is self-contained because the application using the service does not have to depend on anything other than the service itself, and self-describing because all the information on how to use the service can be obtained from the service itself. The descriptions are centrally stored and accessible through standard mechanisms.
Instead of requiring programmers to establish and maintain links between applications, services are loosely coupled, making connections simpler and more flexible, and allowing application architects to more easily find and understand services offered by other cooperative applications. However, the problem that exists with services is that they are often designed to expose functionality of individual applications and, thus, are too limited to be efficient building blocks for enterprise-wide business processes. A solution to this shortfall has been the migration to a Service Oriented Architecture (SOA). The SOA is an open architecture middleware, which builds on the benefits of services. An example of an SOA can be found in the Enterprise Service Framework (ESF), which is commercially available from SAP AG, Walldorf, Germany. The term “SOA” may also be used to refer to “distributed objects” architecture, such as CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Component Object Model).
The SOA enables the abstraction of business objects (BO), modeled as services (also referred to as enterprise services), from actual applications. Aggregating services into business-level enterprise services may provide more meaningful building blocks for the task of automating enterprise-scale business scenarios. Enterprise services allow IT organizations to efficiently develop composite applications, defined as applications that compose functionality and information from existing systems to support new business processes or scenarios.
The SOA also enables the use of an enterprise services repository. The enterprise services repository stores relevant pre-existing enterprise services and makes them available to selected partners and customers. By using the enterprise services repository, these selected partners and customers can use the pre-existing enterprise services to aid in the implementation of new services and corresponding business objects. The term “business object” (BO) represents a physical or logical object of significance to a business, such as a data structure including methods for generating a purchase order. An “object” refers to a software bundle of variables (e.g., data) and related methods. For example, in object-oriented programming, an object is a concrete realization (instance) of a class that consists of data and the operations associated with that data.
When services and business objects are developed, the development of other system components is delayed until the completion of the service and the corresponding business objects. Mockup business objects may be created in order to facilitate the development of other systems components. Often times, regression and mass data testing may need to be done on these services and business objects. These mockup business objects, however, need to be filled with data for regression testing and mass data tests prior to actual development of the business objects. As such, there is a need to improve development of mockup data for these mockup business objects.